What's bright blue that strikes terror into the heart of a personal computer user? It is the dreaded blue screen, which is caused almost always by programming errors. Device drivers are a common source of these errors. A device driver is a software component that permits a computer system to communicate with a device. If a correct driver is not installed in a system, a device cannot be used, because, in most cases, the driver is the only piece of software that understands how to manipulate the hardware used to communicate with the device. Given the proliferation of devices and device drivers, programming errors have exploded exponentially. It is virtually impossible for a programmer to visualize all the interactions between devices and computers or to determine the results of interactions with every other device to which a computer may be interconnected. FIG. 1 shows a system 100 that illustrates these problems and other problems in greater detail.
FIG. 1 illustrates a centralized operating system: Linux operating system 101. The Linux operating system 101 controls and coordinates the use of hardware, such as input/output devices 114, among applications 106 for various users. The Linux operating system 101 centralizes control and coordination by employing three tightly coupled portions of code similar to other UNIX operating system variants: a kernel 102, system libraries 104, and system utilities (daemons) 108. The kernel 102 forms the core of the Linux operating system 101. The kernel 102 provides all the functionality necessary to run processes, and it provides protected access to hardware resources, such as input/output devices 114. System libraries 104 specify a standard set of functions and application programming interfaces through which applications can interact with the kernel 102, and which implement much of the Linux operating system 101. A point of departure from the UNIX operating system variants lies in the operating system interface of the Linux operating system 101, which is not directly maintained by the kernel 102. Rather, the applications 106 make calls to the system libraries 104, which in turn call the operating system functions of the kernel 102 as necessary. System utilities (daemons) 108 are programs that perform individual, specialized management tasks, such as responding to incoming network connections, housekeeping, or maintenance utilities without being called by the user. The kernel 102 is created as a single, monolithic architecture (revealing the UNIX pedigree of the Linux operating system 101). The main reason for the single binary is to improve the overall performance of the Linux operating system 101 by concentrating power, authority, control, and coordination of resources. Everything is tightly coupled in the kernel 102, such as kernel code and data structures. Everything is kept in a single address space, and thus, no expensive context switches are necessary when a process calls an operating system function or when a hardware interrupt is delivered. Not only does the core scheduling and virtual memory code occupy this address space, but all kernel code, including all device drivers 110, file systems, and networking code, is presented in the same single address space.
One problem with such a tightly coupled design is that it is vulnerable. By exposing device drivers 110 in the single address space, these device drivers can act as Trojan horses for housing unreliable code that can deadlock the Linux operating system 101. In almost all cases, the only way for applications 106 to communicate with the input/output devices 114 is by means of device drivers 110 in kernel mode. Kernel mode is the most privileged execution mode of the Linux operating system 101. Privileged means that there is no way for the Linux operating system 101 to monitor the running code of the device drivers 110 or to protect memory from being accessed. Thus, errant kernel-mode device drivers 110 can do whatever they want with no oversight by the Linux operating system 101. One example is the issue of handling hardware-interrupt generation. Due to the asynchronous nature of hardware interrupts, just one programming error in the interrupt handler may deadlock the system or corrupt data in a pathologic, rarely reproducible manner.
Devices of yesteryear seemed stable because their numbers were few and their interconnections to computers were simple. Devices nowadays have proliferated to the benefit of users but such proliferation is attended by a marked increase in the number of device drivers necessary to provide links between applications 106 and input/output devices 114. Without a solution to increase reliability of errant device drivers, users may eventually no longer trust the system 100 to provide a desired computing experience, causing demand for the system 100 to diminish from the marketplace. Thus, there is a need for a method and a system for representing devices as services while avoiding or reducing the foregoing and other problems associated with existing systems.